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ABSTRACT :  The  goal  of  the  Joint  Synthetic  Battiespace  Experiment  (JDPE)  is  to  prove  the  underlying  concept  of 
the  Joint  Synthetic  Battiespace  (JSB)  in  the  context  of  the  warfighters,  i.e.,  USAF  operational  users.  The  JSB  has 
been  conceptualized  and  prototyped  to  support  the  transforming  USAF  into  a  capability  oriented  standard,  such  as 
Global  Strike  Task  Forces  (GSTF),  rather  than  the  current  weapon  platform  centric.  The  new  capability  can  only 
be  realized  by  synergistic  integration  of  existing  and  new  weapons/C2/ISR  systems.  JSB  plans  on  being  the  very 
tool  for  CONOP  development,  R&D,  acquisition,  training,  mission  planning,  rehearsal,  and  even  disposal  of 
component  systems  in  the  future  USAF. 

Initially,  JSB  was  focused  on  supporting  new  weapon/C2/ISR  system  conceptualization,  development,  and 
acquisition.  The  next  application  domain  is  USAF  operational  use.  Air  Combat  Command’s  (ACC)  Tactical  Air 
Command  and  Control  Simulation  Facility  (TACCSF)  conducts  a  quarterly  Desert  Pivot  (DP)  exercise  in 
conjunction  with  Red  Flag  of  Nellis  AFB.  The  first  JSB  Experiment,  which  is  called  JDPE  Event  1,  was  conducted 
during  DP  03-01  in  October,  2002.  This  paper  discusses  the  JDPE  architecture  and  the  details  of  the  JDPE  Event 
1. 


1  Introduction 

In  the  USAF,  there  is  a  newly  emerging  need  to 
support  development,  acquisition,  and  deployment  of 
the  USAF  Task  Forces.  For  example,  the  Global  Strike 
Task  Force  (GSTF),  which  is  one  of  the  TFs,  requires 
a  full  integration  of  all  existing  and  newly  developed 
systems  to  achieve  the  new  level  of  synergistic 
capability  of  the  GSTF.  Flowever,  the  currently 


available  systems  have  been  developed  in  a  stove- 
piped  fashion,  and  they  do  not  facilitate  such 
integration  of  the  GSTF.  Consequently,  by  simply 
putting  together  the  legacy  systems,  the  desired 
synergistic  capability  cannot  be  achieved.  The 
synergism  has  to  be  explicitly  crafted  by  a  careful  plan 
and  implementation  effort. 

Therefore,  designing  the  GSTF,  which  has  never  been 
conceptualized  nor  implemented  before,  is  a  really 
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daunting  task.  The  complexity  will  easily  bog  down 
our  cognition  capability,  and  we  surely  need  a  good 
tool  that  augments  our  limited  cognition  ability,  and  is 
able  to  fully  support  our  effort  of  conceptualization, 
design  and  implementation  of  the  GSTF. 
Unfortunately,  no  existing  tool  currently  exists. 

The  JSB  (Joint  Synthetic  Battlespace)  [1,  2]  is  able  to 
represent  the  full  scope  of  the  GSTF  inside  the 
computers  -  i.e.,  in  the  cyber  space.  Then  the  JSB 
allows  for  us  to  conceptualize,  to  design  and  to  test  the 
GSTF  without  having  a  single  physical  component  of 
the  GSTF.  That  is,  the  JSB  is  the  tool  that  allows  for 
visualization  of  the  future  GSTF  and  makes  us  to 
experience  the  GSTF  that  will  be  available  in  future. 

During  FY03,  the  JSB  effort  has  been  tasked  by  Air 
Force  senior  leadership  to  refine  its  concept  through  a 
series  of  proof  of  concept  experiments.  The  primary 
purpose  of  these  experiments  is  to  show  how  the  JSB 
can  provide  support  for  both  the  operator  and 
acquisition  community  users.  These  proof-of-concept 
experiments  will  be  held  in  the  context  of  the  existing 
events  such  as  Desert  Pivot  (DP),  and  the  Joint 
Distributed  Engineering  Plant  (JDEP),  [3]  while 
leveraging  those  activities.  This  paper  captures  the 
first  experiment  being  executed  in  conjunction  with  the 
DP  events,  which  is  called  JSB  Desert  Pivot 
Experiment  (JDPE)  Event  1.  The  DP  Event  was 
conducted  at  the  Theater  Aerospace  Command  and 
Control  Simulation  Facility  (TACCSF).  The  JSB 
development  effort  was  managed  by  the  Electronic 
Systems  Center  (ESC).  The  JDEP  Event  1  was 
conducted  by  remotely  connecting  the  TACCSF  DP 
facility  and  the  JSB  in  Command  and  Control 
Enterprise  Integration  Facility  (CEIF)  of  ESC  over  a 
classified  long  haul  network  between  two  facilities. 
The  JDPE  Event  1  occurred  during  October  28  through 
November  1,  2002. 


2  Goals  of  JDPE  Events 

The  vision  of  the  JSB  is  to  provide  a  simulation 
capability  that  can  support  a  number  of  different  types 
of  users  -  including  the  operator  and  the  acquisition 
communities.  This  vision  is  approached  by  providing 
authoritative  representations  of  warfighting  capabilities 
and  the  natural  environment  that  can  be  easily 
integrated  to  create  a  realistic  depiction  of  the 
operational  battlespace.  This  “synthetic”  battlespace 
can  then  be  used  to  support  operational  activities  such 
as  training,  mission  rehearsal,  mission  planning,  and 
decision  support  as  well  as  the  acquisition  of 
warfighting  capabilities  that  include  concept  definition, 
development,  test,  deployment,  and  sustainment.  The 
primary  goal  of  the  FY03  DP  events  involving  the  JSB 


is  to  experimentally  prove  how  a  common  simulation 
capability  can  support  both  the  operator  and  the 
acquisition  community  users.  A  secondary  goal  is  to 
evolve  a  common  simulation  capability  so  it  can  better 
support  both  communities  of  users.  The  Desert  Pivot 
Exercises  can  provide  a  realistic  environment  by 
portraying  a  natural  real  world  setting:  front-line 
warfighting  capability  and  remotely  located 
engineering  support. 


3  JDPE  Objectives 

To  accomplish  the  above  experiment  goals,  a 
representative  engineering  problem  of  importance  to 
the  warfighter  was  examined  using  the  same  simulation 
capability  that  supports  the  DP  events.  The  DP 
simulation  capability  has  previously  always  been  used 
to  support  warfighter  operational  readiness. 
Additionally,  if  needed,  the  DP  simulation  components 
are  slightly  modified  so  they  can  better  support  the 
analysis  of  the  selected  engineering  problem  and 
operator  readiness.  For  JDPE  event  1,  the  assessment 
of  an  Intelligence  Surveillance,  and  Reconnaissance 
(ISR)  asset  management  capability  has  been  selected  as 
the  engineering  problem.  The  incorporation  of 
synthetic  weather  into  the  ISR  asset  management 
capability  and  into  the  DP  White  Cell  has  been  selected 
as  a  simulation  capability  improvement  for  both 
operator  readiness  and  acquisition  engineers.  The 
objectives  specifically  are: 

•  Integrate  an  ISR  asset  management  capability 
into  JDPE  event  1  and  use  the  DP  simulation 
capability  to  assess  the  impact  to  operator 
situational  awareness  and  the  ability  of 
engineers  to  effectively  use  the  simulation 
capability  to  perform  the  assessment. 

•  Integrate  a  synthetic  weather  representation 
into  the  JDPE  event  1  to  assess  the  impact  to 
operator  situational  awareness  (as  a 
component  of  overall  operator  readiness)  and 
the  impact  to  engineers  to  effectively  assess 
the  ISR  asset  management  capability. 

The  original  intention  for  the  ISR  asset  management 
capability  was  to  use  the  ISR  Manager.  Due  to  real 
world  contingencies  and  the  resulting  unavailability  of 
an  ISR  Manager  for  JDPE  event  1,  ISR  Warrior  was 
used  instead.  For  synthetic  weather,  the  JSB  weather 
service,  which  has  its  genesis  in  the  Defense  Modeling 
&  Simulation  Office  (DMSO)  Ocean  Atmospheric 
Space  Environment  Service  (OASES),  was  chosen. 
Raytheon  provided  the  ISR  Warrior  capability  and 
Northrop  Grumman  provided  the  synthetic  weather 
service  support.  The  original  intention  was  to  perform 
engineering  assessments  on  the  ISR  asset  management 


capability  and  the  impact  of  inclusion  of  weather  in  the 
context  of  Time  Critical  Targeting  (TCT)  as  follows: 

•  Assess  what  standards  are  needed  to  improve 
the  ease  of  integrating  simulation  components 
into  the  simulation  capability  being  used  for 
JDPE  1. 

•  Assess  what  standards  are  needed  to  improve 
the  interoperability  of  simulation  components 
participating  in  JDPE  event  1 . 

•  Assess  what  changes  in  accuracy  to  the 
simulation  components  participating  in  JDPE 
event  1  are  needed  to  create  a  more  realistic 
representation  of  the  operational  battlespace 


4  JDPE  Approaches 

To  achieve  the  above  goals  and  objectives,  the 
following  approaches  will  be  used: 

1.  Evolutionary  spiral  experimentation 

Four  events  were  proposed  in  conjunction 
with  the  quarterly  DP  exercises  planned  in 
FY03.  Starting  from  a  very  simplistic  but 
operationally  significant  event,  the  JDPE 
should  continuously  increase  in  operational 
and  acquisition  user  relevance  as  the  four 
events  will  be  accomplished  throughout 
FY03. 

2.  Conduct  the  experiment  as  non- 
intrusive  to  the  Desert  Pivot  Experiments 
as  possible 

Because  of  the  importance  of  not  impacting 
real  world  operator  readiness,  the  JDPE 
events  will  not  attempt  to  adversely  impact  the 
DP  events  and  the  accomplishment  of  the 
event’s  operator  objectives. 

3.  Maximize  synergy  of  two 

operations  at  the  C2  Enterprise  Integration 
Facility  (CEIF)  and  TACCSF 

Due  to  limited  resources,  the  success  of  JDPE 
will  rely  on  the  creative  and  synergistic 
collaboration  between  the  DP  and  the  JSB 
teams.  This  will  require  both  teams  to  work 
closely  together  to  develop  an  innovative 

approach  to  increase  the  value  of  the  JDPE 
events. 

4.  Employ  disciplined  system 

engineering 

Since  this  is  a  proof  of  concept  experiment,  a 
disciplined  systems  engineering  approach  will 
be  taken  for  each  JDPE  event.  To  accomplish 
this,  plans  for  development,  integration, 
testing,  support  and  assessment  will  be 
generated. 

5.  Adopt  a  well  defined  engineering 
and  operational  assessment 


Key  to  the  success  of  the  JDPE  events  is  a 
rigorous  assessment  of  the  results  generated 
during  the  event.  A  rigorous  assessment  will 
allow  for  the  Air  Force  to  quantitatively 
understand  what  JSB  capabilities  are  needed, 
the  needed  technology,  and  the  desired 
approach  to  provide  a  useful  capability  that 
supports  both  the  operator  and  acquisition 
community  users. 

5  The  JSB  DP  Experiment  (JDPE) 
Architecture 

The  comprehensive  JDPE  Architecture  is  shown  in 
Figure  1.  It  includes  the  weather  service  plus  two 
possible  configurations  for  providing  the  ISR  asset 
management  capability/functionality  by  either  ISR 
Warrior  or  ISR  Manager. 
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Figure  1:  JSB  Desert  Pivot  Experiment  (JDPE) 
Architecture 


5.1  C2  Enterprise  Integration  Facility  (CEIF) 

The  CEIF  has  the  JSB  prototype  and  provides  ISR 
Management  Server  Functionality  to  the  JDPE. 

JSB  Prototype 

It  is  composed  of  sensor  simulation  components 
(EO/IR/SAR/GMTI),  platform  simulation  components 
(F-15E,  JSTARS,  AWACS,  RJ,  Pelican,  Ground 
Vehicles,  SAM  Threats,  etc),  and  the  Common 
Synthetic  Environment  (CSE),  which  is  a  correlated 
multi-spectrum  dynamic  synthetic  environment.  The 
CSE  also  has  a  weather  component  called  OASES 
which  is  able  to  act  as  a  synthetic  weather  generator. 

ISR  Management  Server  Functionality 

The  ISR  asset  management  capability  means  both  ISR 
Management  Server  and  Client  functionalities.  The 
CEIF  provides  the  ISR  Management  Server 


functionality  and  associated  engineering  support  to  the 
client.  The  server  functionality  is  represented  in  Figure 
1  by  either  the  ISR  Warrior  Server  or  the  ISR  Manager 
Remote  in  conjunction  with  an  ISR  Manager  Flost. 
When  available  for  future  JDPE  events,  the  ISR 
Manager  Flost  will  be  physically  located  in  either  the 
DGS-1  or  at  a  Northrop  Grumman  facility. 

5.2  TACCSF 

TACCSF  has  the  DP  exercise  support  capability  and 
the  client  functionalities  provided  by  the  JDPE  event. 

DP  Exercise  Support  Capability 

The  TACCSF  supports  DP  exercises  with  three  major 
capabilities.  These  include  virtual  simulations 
composed  of  C2  ISR  assets  (i.e.,  E3,  E5,  UAV  virtual 
simulators),  CRC,  and  reconfigurable  cockpit 
simulators;  constructive  simulation,  which  has  thee 
components:  air,  ground  and  threat  simulations  with 
each  of  them  represented  by  STAGE,  JCATS,  and 
MSIM,  respectively;  and  the  White  Cell  operation, 
which  creates  a  realistic  operational  environment  by 
controlling  and  intervening  in  the  operations  of  the 
constructive  simulation  in  the  TACCSF. 

Weather  Client 

An  OASES  client  provides  the  weather  client  function. 
This  function  was  added  to  the  White  Cell  in  the 
TACCSF  so  that  real  time  or,  if  needed,  simulated 
weather  effects  can  be  added  to  the  TACCSF’s 
simulation  capability. 

ISR  Management  Client  Functionality 

The  ISR  Management  Client  functionality  can  be 
provided  by  either  an  ISR  Warrior  Client  or  ISR 
Manager  Remote.  This  functionality  was  initially  be 
added  to  the  White  Cell  located  at  the  TACCSF  to 
improve  and  to  assess  the  ISR  asset  management 
capability. 

Combined  Air  Operational  Center-Nellis  (CAOC- 
N) 

The  (CAOC-N)  participates  in  DP  Exercises.  The  plan 
is  to  provide  the  ISR  Management  Client  function  in 
CAOC-N  in  future  JDPE  events  by  providing  a  ISR 
management  client  at  the  CAOC-N  from  a  server 
located  at  the  CEIF. 


5.3  Network  Connectivity 

The  TACCSF  and  CEIF  were  connected  through  the 
available  network.  ISDN  Integrated  Services  Digital 
Network  (ISDN),  Tl,  Defense  Information  System 
Network  Leading  Edge  Services  (DISN-LES),  and 
Defense  Research  Engineering  Network  (DREN)  were 
possible  connection  options.  However,  due  to  the 


timely  availability  of  the  ISDN,  the  ISDN  connectivity 
was  selected  for  JDPE  event  1 . 


6  JDPE  Event  1  Architecture 

As  stated,  the  JDPE  may  include  four  events  in  FY03 
with  each  occurring  during  the  scheduled  quarterly  DP 
exercises.  The  events  will  gradually  increase  in 
complexity  and  capability.  The  first  two  events  are 
planned  to  incur  no  or  little  change  to  the  current 
TACCSF  simulation  models  by  making  the  human 
operators  in  the  White  Cell  consume  new 
data/information  that  are  available  through  the  weather 
client  and  ISR  Management  Client  function.  The  third 
and  fourth  events  could  result  in  modifications  to  the 
TACCSF  simulation  models  so  they  can  use  the  newly 
available  weather  and  ISR  asset  management  data 
directly.  Throughout  the  four  events,  the  goal  is  to 
evolve  the  current  simulation  capability  used  for  the 
DP  exercises  to  be  more  supportive  of  operators  and 
acquisition  engineers’  needs  concurrently. 


Therefore,  the  JDPE  Event  1  was  planned  as  the  least 
intrusive  joint  experiment  event,  and  executed  in 
conjunction  with  DP  03-01,  which  was  the  first  DP 
Exercise  in  FY03.  The  detailed  Event  1  Architecture  is 
shown  in  Figure  2. 
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Figure  2:  JDPE  Event  1  Architecture  and  Data 
Flow 


As  shown  in  Figure  2,  the  data  generated  by  the  JDPE 
was  not  directly  consumed  by  the  simulation  models  in 
the  TACCSF  during  the  DP  Exercise  03-01.  Instead, 
the  data  generated  by  the  JDPE  was  provided  to  the 
White  Cell  operators  through  the  OASES  weather 
client  and  the  ISR  Warrior  Client.  Both  clients’ 
Graphical  User  Interfaces  (GUIs)  were  provided  for 
the  While  Cell  operators. 


To  provide  the  weather  data,  the  FTP  weather  server 
was  planned  to  feed  real  time  weather  to  the  OASES 
server,  whieh  is  loeated  in  the  CEIF  * .  Then,  the 
OASES  server  eonverted  the  real  time  weather  into 
data  eompatible  with  FILA/RTI  and  sent  the  data  to  the 
OASES  elient,  whieh  was  loeated  in  the  TACCSF, 
through  the  RTI  that  eonneets  between  TACCSF  and 
CEIF  over  the  ISDN  eonneetion.  The  3D/2D  graphies 
GUI  terminal  of  the  OASES  elient  then  displayed 
weather  for  the  White  Cell  operators.  The  OASES 
server  was  also  eapable  of  generating  weather 
synthetieally  of  virtually  any  type. 

The  ISR  Warrior  Server,  whieh  is  eomprised  of  the 
ISR  information  proeessing  server  with  a  GUI  for 
human  operator  interaetions  and  a  web  server,  provides 
the  proeessed  ISR  data  to  the  ISR  Warrior  elient.  As 
such,  the  ISR  Warrior  client  is  essentially  a  web 
browser  that  receives  the  ISR  Warrior  information 
from  the  ISR  Warrior  Web  server.  The  ISR  Warrior 
server,  on  the  other  hand,  accepts  raw  ISR  data  from 
the  ISR  assets  as  its  inputs.  During  JDPE  event  I,  the 
UAV  simulator  in  the  TACCSF  (i.e.,  AFSERS)  fed 
video  to  the  ISR  Warrior  serve  located  in  the  CEIF. 

As  mentioned  above,  ISDN  had  been  selected  to 
connect  the  CEIF  and  TACCSF  due  to  the  ready 
availability  of  the  ISDN  for  both  sites  in  October  2002. 
However,  the  bandwidth  was  quite  narrow  to  1 28Kbps 
which  limited  the  amount  of  information  exchanged 
between  the  two  sites.  Even  so,  a  preliminary  analysis 
showed  that  the  ISDN  was  able  to  meet  the  bandwidth 
requirements  of  the  JDPE  Event  1.  The  preliminary 
bandwidth  analysis  is  shown  in  Table  1  and  Table  2. 


Table  1:  Bandwidth  Requirement  of  Data 
Traffic  from  CEIF  to  TACCSF  for  JDPE 
Event  1 
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Server 

ISR 

Warrior 

Client 

100Kbps 

ISDN 

OASES 

Server 

OASES 

Client 

28Kbps 

ISDN 

Table  2:  Bandwidth  Requirement  of  Data 
Traffic  from  TACCSF  to  CEIF  for  JDPE 
Event  1 


Data  traffic  from  TACCSF  to  CEIF 

From 

To 

Bandwidth 

Comm 

Channel 

UAV 

Video 

ISR 

Warrior 

Client 

100Kbps 

ISDN 

ISR  Asset 
Tracks 

ISR 

Warrior 

Client 

28K 

ISDN 

Although  the  UAV  video  feed  requires  as  high  as  3 
Mbps  or  more  if  a  conventional  approach  is  used,  for 
the  Event  1,  a  special  video  compression  technology 
called  MJPEG  (Motion  JPEG)  is  adopted.  This 
approach  allows  for  transmitting  the  UAV  video  over  a 
lOOK  bandwidth  communication  pipe  such  as  our 
ISDN  connectivity.  By  the  way,  pushing  the  UAV 
Video  through  such  a  narrow  bandwidth  actually 
mimics  a  real  world  situation  in  which  only  is  a  limited 
bandwidth  available.  The  JDPE  planned  assessment  of 
the  impact  on  the  performance  of  ISR  management  and 
captured  the  engineering  performance  data  during  the 
JDPE  event  03-01. 

7  JDPE  Event  1  Network  and  System 
Diagram 

7.1  CIEF  Network  and  System  Diagram  for 
JDPE  Event  1 

The  JDPE  Event  I  connected  the  TACCSF  and  the 
CEIF  through  ISDN.  Data  communication  over  the 
ISDN  connectivity  was  enabled  by  the  ADTRAN 
Modem.  The  data  stream  in  and  out  of  the  ADTRAN 
Modem  was  encrypted/decrypted  by  a  KIV-7  crypto 
device.  The  decrypted  data  went  through  the  CISCO 
route  and  was  connected  to  the  100  BaseT  Ethernet 
Local  Area  Network  (LAN).  This  connectivity  is 
shown  in  Figure  3. 


*  The  live  FTP  weather  data  feed  was  planned. 
However,  the  live  feed  option  was  dropped  due  to  the 
long  certification  process.  Instead,  a  “sneaker  nef’ 
approach  is  adopted.  The  weather  data  is  periodically 
recorded  on  a  CDROM,  and  loaded  to  the  weather 
server.  Obviously,  this  situation  will  be  more 
automated  for  the  subsequent  events  planned  during 
FY03. 
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Figure  3:  CEIF  Network  External  and  Internal 
Connectivity  for  JDPE  Event  1 


Encoder  Pentium  IV  Client 

Linux  NT 


The  data  traffie  input  from  the  CEIF  to  the  TACCSF 
was  encrypted  by  a  KIV-7  Crypto  Device. 

The  100  BaseT  Ethernet  LAN  in  the  CEIF  connected 
the  OASES  Weather  Server  (Linux),  the  ISR  Warrior 
Server  (2  Sun  Ultra  60  workstations),  and  the  ISR 
Warrior  Web  Server  (NT)  as  also  shown  in  Figure  3. 


I  192.168.8.20  192.168.8.21  192.168.8.22 

Figure  4:  TACCSF  Network  and  System  Diagram 
for  Event  1 

The  specifications  of  the  computer  hardware  and 
software  at  the  TACCSF  are  listed  in  Table  4: 


The  specifications  of  the  systems  for  Event  1  at  the 
CEIF  are  shown  in  Table  3: 


Table  3:  System  H/W  and  SAV  Spec  at  CEIF  for 
Event  1 


System 

Name 

H/W 

Spec 

OS 

Softwar 

e 

ISR  Warrior 
(Server) 

2  Sun 

Ultra-60 

SunOS 

2.6 

ISR 

Warrior 

SW 

ISR  Warrior 
(Web  Server) 

1  NT 

Web 

Server 

Windows 

2000 

Professio 

nal 

Apache 

Web 

Server 

SW 

OASES 

(Server) 

1  Linux 
Pentium 

IV  PC 

Linux 

Redhat 

7.2 

OASES 

V1.0 

Server 

Video 

Decoder 

Enerdyne 

LNX7000 

MJPEG 

Decoder 

Linux 

Kernel 

Enerdyn 

e 

LNX700 

0 

MPJEG 

Decoder 

SW 

Table  4:  System  H/W  and  S/W  Spec  at  TACCSF  for 
Event  1 


System 

Name 

H/W 

Spec 

OS 

Software 

ISR 

Warrior 

(Client) 

1  NT 

Pentium 

IV  PC 

Windows 

2000 

Professiona 

I 

MS 

Internet 

Explorer 

Version 

6.0 

OASES 

(Client) 

1  Linux 
Pentium 

IV  PC 

Linux 

Redhat  7.2 

OASES 

V1.0 

Client 

Video 

Encode 

Enerdyne 

LNX 

7000 

MJPEG 

Encoder 

Linux 

Kernel 

Enerdyn 

e  LNX 

7000 

MJPEG 

Encoder 

SW 

8  JDPE  Event  1  Key  Activities 

JDPE  Event  1  was  performed  rapidly.  From  the  initial 
design  to  the  DP  participation,  it  took  slightly  less  than 
two  months.  The  key  activities  are  summarized  as 
following. 


TACCSF  Network  and  System  Diagram  for 
Event  1 

The  ISDN  network  in  TACCSF  essentially  used  the 
same  equipment  as  described  above  for  the  CEIF.  This 
configuration  is  shown  in  Figure  4.  As  shown  in  the 


1.  Design  JDPE  Architecture  (9/13/02  - 
9/26/02) 

a.  The  initial  version  of  the  JDPE 
architecture  and  associated  design, 
which  was  a  power  point  briefing, 
was  introduced  during  the  JDPE 


Event  1  initial  planning  conference 
(IPC). 

b.  The  JDPE  architecture  for  Event  1 
was  developed.  TACCSF  and  CEIF 
team  collaborated  to  develop  the 
architecture.  Once  completed,  it  was 
incorporated  into  the  JDPE  Test  & 
Support  Plan. 

2.  Establish  Connectivity  (9/20/02-10/21/02) 

a.  The  first  task  was  to  identify  the  type 
of  connection  to  be  used. 

The  connectivity  between  the  CEIF 
and  TACCSF  was  investigated  by 
both  communications  officers  of  the 
CEIF  and  the  TACCSF.  For  the 
Event  1,  ISDN  was  chosen.  It  was 
decided  that  a  T1  connection  would 
be  pursued  for  implementation 
beginning  in  Event  2  or  3. 

b.  The  second  task  was  to  establish 
connectivity  between  TACCSF  and 
CEIF  at  Secret  Level. 

Although  the  ISDN  connection 
existed  between  the  TACCSF  and 
CEIF  prior  to  the  JDEP  Event  03-01, 
a  MOA  between  the  two 
organizations  was  still  needed  to 
support  the  JDPE  Event  1 .  The 
technical  glitch  and  the  technical 
support  issue  from  the  provider 
impacted  on  this  schedule  and 
delayed  more  than  one  week  to 
complete  the  ISDN  connectivity. 

3.  Construct  JDPE  Test  and  Support  Plan 
(9/23/02-10/07/02) 

a.  Generate  First  Cut  JDPE  T&S  Plan 
and  distributed  for  review  (10/04/02) 
The  JDPE  Test  &  Support  Plan 
included  the  premises,  objectives, 
goals,  approach,  roles  and 
responsibilities,  key  events,  schedule, 
test/integration,  and  assessment 
plan.  The  document  also  defined  the 
scope  of  the  experimentation. 

b.  ESC  Approval  for  the  Version  1.0  of 
the  JDPE  T&S  Plan  (10/07/02). 

4.  Provide  JDPE  system/test  engineering 
support  (10/01/02  - 11/01/02) 

a.  CEIF  System/Integration  Test 
Engineering 

This  was  composed  of  three  tasks. 
JDPE  Eventl  Systems  engineering 
(10/01/02  -  10/11/02);  Individual 
System  Testing  at  the  CEIF  is  the 
second  (10/07/02  -  10/11/02);  and 
the  Integration  Test  at  the  CEIF 
(10/14/02  -  10/18/02,  was  the  third). 


The  last  task  insures  the  proper 
execution  of  Event  1  at  the  CEIF 
before  sending  the  systems  to  be 
installed  and  tested  at  the  TACCSF. 

b.  TACCSF  Test/Integration 
Engineering 

The  integrated  and  tested  product 
(i.e.,  the  weather  client  and  the  ISR 
Warrior  Client)  was  scheduled  to  be 
shipped  to  the  TACCSF  and  installed 
by  CEIF  personnel.  A  minimal 
integration  effort  was  required  at  the 
TACCSF  because  the  same  setup 
including  ISDN  connection  was 
tested  at  the  CEIF  as  a  part  of  the 
CEIF  System/Integration  Test 
engineering  process  before  installing 
in  TACCSF. 

5.  Execute  JDPE  Event  1  (10/28/02  - 
11/01/02) 

a.  JDPE  Operational  Assessment 

The  operational  impacts  on 
Distributed  Mission  Planning  (DMT) 
due  to  effects  of  weather 
phenomenon  and  ISR  Management 
functionality  were  assessed. 

b.  JDPE  Engineering  Assessment 

The  JDPE  was  also  designed  to 
support  engineering  assessment  in 
the  context  of  the  DP  03-1  in  both 
CEIF  and  TACCSF. 

9  Operational  and  Engineering 
Assessments 

The  JSB  participation  (JDPE  Event  1)  in  the  first  DP 
exercise  03-01  of  FY2003,  while  successful,  proved  to 
be  both  challenging  and  exciting.  After  overcoming  a 
few  glitches  at  the  start,  the  two  systems  functioned 
flawlessly  throughout  the  remainder  of  the  exercise  and 
were  well  received  by  the  personnel  who  took  the  time 
to  view  the  JDPE  Event  1.  While  specific  uses  of  the 
two  capabilities  in  the  DP  exercises  did  not  come  out, 
the  TACCSF  staff,  DP  operators,  and  war  fighters 
interviewed  expressed  interest  in  the  JSB  environment 
concept.  Weather  effect  capabilities  are  undergoing  an 
independent  review  at  TACCSF  and  could  become  part 
of  the  future  training  operations.  There  was  great 
interest  for  the  ISR  Warrior  capabilities.  However,  in 
order  to  be  a  part  of  regular  exercises,  a  more  focused 
role  in  the  DP  exercise  needs  to  be  defined.  The 
concept  behind  the  ISR  Warrior,  that  is  the  remote 
server  with  local  client,  could  be  extended  to  many 
other  simulation  areas  to  consolidate  the  efforts  in  both 
sections  of  the  white  cell. 


Specifically,  the  JDPE  Event  1  team  performed  a 
deliberate  operational  and  engineering  assessment 
during  the  DP  03-01.  The  impact  and  utility  of  the  JSB 
provided  ISR  asset  management  and  weather  effect 
capabilities  to  operator  situational  awareness  was 
assessed  by  direct  observation  of  the  DP  exercise, 
interviews  with  the  operators  conducted  before,  during, 
and  after  each  day  activities,  and  by  direct  observation 
of  DP  participants’  interaction  with  the  two  capabilities 
throughout  the  exercise  period. 

The  ISR  management  and  weather  systems  were 
installed  in  the  section  of  the  white  cell  responsible  for 
providing  stimuli  to  the  warfighters  in  the  exercise. 
However,  the  white  cell  personnel  had  full  knowledge 
of  the  scenario  and  the  training  objectives  for  each 
evening.  Thus  they  did  not  have  a  critical  need  for  the 
additional  ISR  capabilities  provided  by  those  systems. 
The  DP  exercise  was  also  conducted  without  weather 
effects.  Again,  the  utility  of  the  weather  displayed  to 
them  was  minimal.  Furthermore,  the  white  cell 
personnel  were  too  busy  to  absorb  the  newly 
introduced  capability  and  use  them  in  the  exercise. 
They  in  the  white  cell  did  not  have  any  available  time 
to  conduct  activities  outside  their  training  duties. 

Even  so,  TACCSF  personnel  are  currently  reviewing 
weather  effect  capabilities  to  have  prepared  a  set  of 
requirements  for  the  exercises  they  will  conduct.  Part 
of  this  review  is  an  analysis  of  weather  the  capability 
will  add  or  detract  from  the  training  objectives  they 
must  comply  with.  Opponents  to  the  addition  have 
pointed  out  that  warfighters  have  separate  training  to 
prepare  them  for  weather  effects  during  their 
operations  and  thus  the  TACCSF  training  does  not 
need  to  be  further  complicated  by  the  addition. 
However,  they  generally  agree  on  the  value  of  weather 
effects  in  the  arena  of  mission  rehearsal  activities. 

The  server  and  client  setup  between  the  CIEF  at  ESC 
where  the  support  engineers  reside  and  the  TACCSF 
where  the  front-line  warfighters  conduct  a  war  (i.e., 
training  in  this  case)  was  successfully  executed  and 
well  conceived  by  the  DP  people  in  TACCSF.  This 
portrays  the  future  battle  that  USAF  will  fight  in  a 
network  centric  fashion. 

Finally,  the  engineering  data  was  collected  in  the  area 
of  network  latency,  bandwidth  usage,  and  unscheduled 
server-down  in  the  CEIF.  The  latter  part  simulated  the 
server  crash  in  the  context  of  the  remote  engineering 
support  to  the  front-line  warfighters  between  the  CEIF 
and  the  TACCSF.  The  network  latency  was  almost 
constant  due  to  the  sole  usage  of  the  long  haul  network 
for  the  JDPE  Event  1  only.  Most  of  all,  we  could  send 
a  real  time  video  image  from  a  simulated  Predator  over 
the  ISDN  connection.  The  Enerdyne  video  compressor 


could  compress  the  real-time  video  stream  to  fit  in  a 
100k  bps  bandwidth.  The  rest  of  the  bandwidth,  28k 
bps,  was  used  to  support  the  server  and  client 
communication  between  the  ISR  Warrior  and  the 
OASES  Weather  Server.  .  The  simulated  server  crash 
could  stress  the  current  server-client  system  design. 
The  ISR  Warrior  was  only  the  system  participated  in 
this  test,  which  was  by  no  means  a  formal  assessment. 
The  ISR  Warrior  could  restore  its  normal  operation 
without  causing  any  client  crash  or  requiring  rebooting 
the  client.  It  showed  a  solid  robust  performance  under 
the  simulated  server  crash  scenario.  The  only  area  for 
improvement  would  be  the  addition  of  a  monitor  for 
the  health  of  the  server.  The  first  reaction  on  the 
simulated  crash  from  the  client  user  was  repetitive 
mouse  clicking.  Initially,  the  user  at  the  client  did  not 
have  the  means  to  know  the  cause  of  the  sluggish 
response.  It  could  have  been  caused  by  one  of  the 
various  causes:  the  slow  operation  of  one  of  the 
servers,  network  congestion,  or  a  server  crash.  It  took 
about  a  minute  or  so  before  the  user  figured  out  that 
the  server  crash  at  the  other  side  of  the  network.  If  the 
user  had  never  been  informed  that  there  would  be  a 
server  crash,  the  user  would  have  been  waited  longer 
while  hoping  for  clearing  some  unknown  causes 
affecting  the  troubling  operation.  As  a  result,  the 
operator’s  frustration  level  could  have  been  much 
higher  than  that  of  the  above  simulated  server  crash 
during  the  JDPE  if  there  was  no  pre-announcement 
about  the  simulated  server  crash. 

10  Summary  and  Conclusion 

The  DP  is  a  quarterly  training  exercise  for  operational 
users  in  the  context  of  Distributed  Mission  Training 
(DMT).  The  DP  provided  an  excellent  operational 
environment  for  the  JSB,  and  the  JSB  successfully 
proved  its  utility  in  the  environment  as  reported  in  this 
paper.  Previously,  the  JSB  mainly  reported  its  utility 
in  the  acquisition  and  engineering  domains  [4,  5]. 

The  subsequent  JDPE  events  with  the  TACCSF  DPs 
will  incrementally  bring  more  capabilities  to  the  DPs 
while  achieving  the  goal  JDPE  architecture  shown  in 
Figure  1.  When  the  goal  JDPE  architecture  is  fully 
implemented,  the  JSB’s  full  capabilities  will  be  readily 
available  to  the  TACCSF  DP  exercise  participants 
while  significantly  raising  the  realism  and  values  of  the 
DPs.  Eventually,  the  DPs  in  conjunction  with  the  JSB 
will  be  able  to  provide  a  full  mission  rehearsal 
capability  in  a  network  centric  environment  for  USAF. 
Then,  one  of  the  JSB  vision  areas,  supporting  USAF 
operations,  will  be  achieved.  The  JSB  team  is  also 
currently  closely  working  with  several  acquisition 
programs  such  as  the  Multisensor  Command  and 
Control  Constellation  (MC2C). 


The  JSB  team  greatly  appreeiates  the  professional  and 
technically  competent  support  given  by  the  TACCSF 
DP  personnel  during  the  JDPE  Event  1.  Without  their 
technical  support  and  other  assistance,  we  could  have 
not  achieved  the  level  of  success  at  the  DP.  . 
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